A number of examples are provided to help illustrate how AliasNames function. This includes a Client using an AliasName Server, inside of a Server, in an aggregating Server and in a GDS.

Figure A.1 illustrates how this model can be used inside of a Server. This sample includes multiple instances of AliasNameCategoryType. The figure illustrates that Objects could be referenced by more than one instance of AliasNameType.

Figure A.1 – AliasNames in a Server example

The figure describes an information model for a well. This model contains a number of other Objects, which have Variables that are to be available via a standardized naming scheme. The model also includes a configuration for a Pub/Sub dataset that provides the Variables defined in the well.

The AliasName model includes the standard organization items that are required in this document. In addition, the model also defines an extra organizational item for grouping the well information. The example illustrates AliasNames that are both TagVariables and Topics.

An aggregating Server would have much the same structure as the Server in the first example, with the exception that in the aggregating Server the target Nodes referenced by the AliasFor Reference could be in other Servers. Figure A.2 provides an illustration of an example aggregating Server. The Server could have a much more complex AddressSpace than provided in the example.

Figure A.2 – Aggregating AliasNames Server example

The aggregating Server has a choice in that it could just provide the link to the underlying Node (blue lines) or it could provide a link to the replicated Node in the aggregated Server’s AddressSpace (red lines).

The standalone AliasNames Server illustrated in Figure A.3 provides a list of AliasNames that reference Nodes in multiple separate Servers. This type of configuration could be used for Servers that do not have the resources to manage AliasNames on their own. It could also be used in a system where the configuration of AliasNames occurs after the devices that are represented by the Servers have already been deployed or if a Server just does not have support for AliasNames. The standalone AliasNames Server can function as a lookup Server for all of the AliasNames defined in the system. It is the responsibility of the standalone AliasNames Server to ensure that the mapping of AliasNames to actual Nodes is correct.

Figure A.3 – AliasNames Server example

An aggregating Server as shown in Figure A.4 could also collect all of the AliasNames defined in underlying Servers and just build a composite list of these AliasNames. Since all of the AliasNames are required to exist under the mandatory Aliases Object, it is simple for a Server to browse the AddressSpace and build a list. The aggregating Server would be required to merge all AliasNames listed under the well-known Objects. Some information models could define their own well known AliasNameCategoryType Objects, which would then also need to be merged. An aggregating Server could easily have the same AliasNames with multiple NodeIds. For example, if a temperature sensor were to be connected to two Servers for redundancy, the same AliasName TI101 could exist in both Servers. The aggregating Server would simple report two ExpandedNodeIds to any Client that requested TI101.

Figure A.4 – Aggregating AliasNames Server example

In the above example, if the Temperatures AliasNameCategoryType instance were defined locally in the Server and not defined in a standard namespace then two instances of the Temperatures AliasNameCategoryType will exist in the aggregating Server with different namespaces.

The GDS could include additional optional behaviour which this example illustrates. What is required is the availability of all AliasNames in the mandatory TagVariables and Topics folder, but a GDS could also choose to replicate or even merge the additional AliasNameCategoryType instances from the Servers that have registered. Figure A.5 provides an illustration of a GDS that merged the AliasNameCategory instance into a tree. It is required that AliasNameCategories be aggregated by the GDS, but the structure of these categories is not defined.

Figure A.5 – GDS with merged AliasNames example

For additional information about a GDS and AliasNames see Annex B.

AliasNames allow a Client to find TagVariables or Topics easily. Many industrial systems assign tags to specific measurement or sensors. These tags follow established nomenclatures. An example tag is TI101, which is a temperature indicator at a specific location in a plant. The example nomenclature is defined in ANSI/ISA-S5.1-1984 (R 1992), but this specification does not provide or even suggest any nomenclature. A Client could be configured to display or use the information provided by the sensor TI101, but the actual address/location of this sensor is often not known when the Client is configured. AliasNames can be used to resolve this tag to the actual sensor in the system.

The Client, on start-up or when it needs to access the tag, would call FindAlias on a local Server, aggregating Server or GDS depending on how a system is configured. A Client could select which AliasName source to call via a configuration setting. The FindAlias Method call would return a list of all ExpandedNodeIds that the AliasName References. It is important to note that there could be more than one Node referenced by an AliasName and that the Client must be prepared for this. The first Node in the list of referenced Nodes returned by FindAlias Method is the Node that the Server feels is the best match for the requested tag. The returned list could also return more than one instance of AliasNameType and each could have their own list of referenced Nodes. If the Method call was on a GDS or aggregating Server, the Client would need to read the ServerArray to resolve which Server the ExpandedNodeId was referencing. This would be the last piece of information that a Client would need to be able to follow a normal connection pattern to obtain values from the Node.

AliasName could also be configured to provide other information, such as Pub/Sub information, but again it would only be the information that is needed to initially subscribe to an item.